fix: Align all 0x34 and 0x36 framing bytes - #848
Conversation
gijzelaerr
left a comment
gijzelaerr
left a comment
There was a problem hiding this comment.
The transport-flag mapping is protocol behavior and currently has no regression coverage in this PR. Please add byte-level tests for both sync and async request builders that demonstrate:
- every function in
FLAGS_34_FUNCTION_CODESemits0x34; - an ordinary
CreateObjectremains0x36; - session-key requests retain their existing
0x34override; _delete_session()emits0x34in both clients.
The hardware result is valuable, but without these tests a later request-builder refactor can silently restore the framing mismatch. This is also a prerequisite for #849, whose capture fixtures currently fail without this branch, so the boundary needs to be locked down before merge.
|
I have pushed 1946bd6 to test regressions in the wire format from what you mentioned, but testing there is still a little bit awkward because the payloads are generated in-line, and also not shared between sync and async library. This refactor belongs in a different PR, so I included the basic testing with the |
gijzelaerr
left a comment
gijzelaerr
left a comment
There was a problem hiding this comment.
The transport-flag mapping now has byte-level coverage for session CreateObject, SessionKey overrides, and sync/async DeleteObject, with the shared function-code set covering the common request builders. I ran the S7CommPlus framing and TLS suites locally: 93 passed.
2 participants
Changes
Aligns the transmission with the received bytes when it comes to the transport flags. The C# library has the following definitions:
InitSslRequest.cs:230x30CreateObjectRequest.cs:23,570x36DeleteObjectRequest.cs:230x34ExploreRequest.cs:240x34(with a// or 0x36???comment)GetMultiVariablesRequest.cs:240x34GetVarSubstreamedRequest.cs:230x34SetMultiVariablesRequest.cs:240x34SetVariableRequest.cs:230x34I aligned based on the testing with a S71500 PLC, and it seems to accept the framing 0x34 or 0x36 in most cases, but sometimes the wrong frame leads to a connection reset. Here are the sent and received frames:
0x300x300x700x360x360x360x340x340x340x360x340x340x340x340x340x360x340x34Once the new codes from the C# library are added, they can be added to the same frozenset to keep compatibility.
PS: I checked if this was the cause why #820 was not working, but that was not the issue.